Types of field you will encounter

You will encounter many date fields throughout Collections:

Date fields have both a data type format (the format a date is entered into a field and stored in the database) and a presentation format (the format a field displays in a record in Display mode). These are usually the same, but can be different (dates might be stored in ISO date format but displayed using an appropriate regional format).

Typically, all date fields across Collections will have the same data type and presentation format, and in the vast majority of cases this will be the ISO date format.

Date fields can be configured to accept dates in five formats (and one deprecated format):

Format	Example
(EUR) dd/mm/yy	31/12/94
(EUR) dd/mm/yyyy	31/12/1994
(ISO) yy-mm-dd	94-12-31 To facilitate the international exchange of data, date fields in Collections are typically set to the ISO date format: yyyy-mm-dd. The ISO date format also accepts partial dates, such as 2020-12 or 2020.
(ISO) yyyy-mm-dd	1994-12-31
(Julian) yyyy-ddd	1994-365
(EUR dd/mm/yyyy	31/01/2002 Though still accepted, this format has been deprecated.

The simplest way to ensure a date is entered in the correct format is to use the calendar pop-up:

Tip

• Enter a year in the field before clicking the Calendar icon; the Calendar pop-up will open to the specified year:

  

Alternatively, key a date in the required format into the field. If the format is yyyy-mm-dd, you would enter something like: 2020-01-28

If the ISO date format has been specified (yyyy-mm-dd), you can enter partial dates, such as: 2020-12 or 2020.

The simplest way to identify the required format is to select a date from the calendar pop-up: a date in the expected format will display:

Entering invalid data in a date field will result in a pop-up that clearly identifies the required format:

Note: It is still possible to enter invalid data in a date field; a date field expects numbers and entering meaningless numbers may be accepted.

An Advanced search for dates

Although date fields in Collections can be configured to accept dates in a number of formats, they typically have a DateIso data format and are stored in your database with a format of yyyy-mm-dd.

Fields with a DateIso data format can also have a presentation format, which determines how they display in the User Interface. A date stored in your database as 2020-10-08 can be configured to display using a European date presentation format, such as 08/10/2020.

As a rule, when your search value is a date, you can specify it using the DateIso data format, yyyy-mm-dd or the presentation format.

The exception to this rule is a date with the Locale date (long) ISO date presentation format in which days and months are in words, e.g.:

Thursday 8 October 2020

In this case your search value can be in the DateIso data format, yyyy-mm-dd or the Locale date (short) format. The format of Locale date (short) and Locale date (long) are determined by your local Windows date settings.

See Advanced search for more details.

An Advanced search for dates

Although date fields in Collections can be configured to accept dates in a number of formats, they typically have a DateIso data format and are stored in your database with a format of yyyy-mm-dd.

Fields with a DateIso data format can also have a presentation format, which determines how they display in the User Interface. A date stored in your database as 2020-10-08 can be configured to display using a European date presentation format, such as 08/10/2020.

As a rule, when your search value is a date, you can specify it using the DateIso data format, yyyy-mm-dd or the presentation format.

The exception to this rule is a date with the Locale date (long) ISO date presentation format in which days and months are in words, e.g.:

Thursday 8 October 2020

In this case your search value can be in the DateIso data format, yyyy-mm-dd or the Locale date (short) format. The format of Locale date (short) and Locale date (long) are determined by your local Windows date settings.

See Advanced search for more details.

Fields in which values are selected from a drop list are called enumerative fields in Collections. Values in these fields are read-only; they are added and, in a multilingual system, translated by your Application Administrator in the Collections administration tool, Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc.. The value that you see in an enumerative field in the User Interface is a display value associated with the current interface language, but the actual value stored in the database is a language-independent neutral value.

There are occasions when it is necessary in Collections to specify a neutral value rather than the display value. When the Field properties box is viewed for an Enumerate field, an Enumeration Values tab lists the drop list's neutral and display values. Here we see the Enumeration Values tab for the Name role (name.type (do)) field in Persons and institutions:

The difference between the neutral and display values is even more pronounced in the Status (current_status (sS)) field:

Although not new to Axiell Collections, free fields and the Free fields panel have been improved and made available across more data sources in Axiell Collections system running the Standard Model application. The Free fields panel provides a location for any data that does not have a native field in Axiell Collections, and it is intended as an alternative, where appropriate, to customization of the application.

When we talk of types of field we typically refer to the field's data type (date and geolocation fields) or a particular quality (inherited fields). In the case of Free fields, it is their purpose that characterizes them.

Most fields in Collections are intended to hold a specific piece of information (an object number, a title, a birth date, and so on) often defined by an industry standard (SPECTRUM or ISAD(G), for instance). Free fields, which are found on a Free fields panel typically near the bottom of the list of tabs in Record details View, provide more flexibility; while not new to Collections, their use in the past was mostly limited to holding data migrated from fields in legacy systems that had no obvious equivalent in Collections.

Note: In systems running Model Applications prior to the Standard Model, there is a single text type of free field.

The release of the Standard Model saw a significant increase in the number of fields and data sources available in Collections so that there is almost certainly a suitable field to hold your data without the need for customization. This has allowed for a new approach to the use of free fields in systems running the Standard Model, and Free fields panels are now intended as an alternative, where appropriate, to customization of the application. To that end, Free fields panels are now available across more data sources; and it is no longer necessary to store all types of data in a generic text field as there are now free fields to hold text, dates and numbers, and there is also a checkbox variant:

Their use is straightforward. You specify the purpose of the field in Type (name the field) and enter the value in the Content field:

Note: As values in the Type field are managed in the System lists data source1 Available in Axiell Collections systems running the Standard Model application., Application Administrators ($ADMIN users) are free to add new values as required.

As each group of fields on the Free fields panel (Texts, Dates, Checkboxes, Numbers) is a repeatable group of fields, you can use the Occurrences drop list in the Record details View toolbar to add / remove / move a group of fields.

If there is no native field for a piece of data, consider whether a free field can be used to hold it, avoiding the need to customize the application.

There are two types of geolocation field in Collections:

• A Geographical Information System (GIS) field, which has a Geo-json data type.

  -OR-

• A field with a Geo location data type.

Place (production.place (VP)) in this example has been configured as a Geo location field:

Both types of field store a location that can be displayed on a map, and both allow a location to be selected on a map and saved to the field, but they do so differently. GIS functionality is a more recent addition to Collections and has superseded the earlier Geo location approach to location mapping.

Here we see geolocations plotted on a map in Map View:

Map View is a licensed add-on to Collections and is not available out-of-the-box (contact Support for details). If it is available in your system, the Map View button will display in the top Toolbar when you are working in a data source The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. that stores location information in fields designed to hold geolocation data. In the example above, birth.place and death.place are geolocation fields and these two locations can be shown on a map.

Details about working with geolocation fields and Map View can be found here.

Geolocation fields: the Geo location and Geo-json data types

Data type
Geo-json	When GIS functionality is enabled in your system, locations are recorded in a Geographical thesaurus Authority data source Authority data sources are used for vocabulary control and they manage the many names and terms referenced by records in almost every other data source. The purpose of a controlled vocabulary is to ensure consistent use of names and terms throughout your records and this is achieved by specifying that a name or term is preferred; then when a non-preferred version of a name or term is selected in a Linked field drop list, it is automatically replaced with the preferred name or term. and location fields throughout Collections can link to a record in this data source. Any of these linked locations in the current The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance. or selected records will then display on a map in Map View. A GIS field in the Geographical thesaurus has a Geo-json data type and can be identified by a map icon beside the field label. In Record details View, the icon indicates whether a location has been saved to the field or not: No location has been saved to the field. When editing a record, click the icon to open an Edit Map location window and add a location (details here). A location has been saved to the field and it will display in Map View: Alternatively, click the icon to open a View Map location window displaying the location on a map. If you are editing the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance., the Edit Map location window will open. Tip: The Edit Map location and View Map location windows are essentially the same as Map View. It may also be possible to search for locations on the Standard tab of the Search box. A searchable GIS field is also identified by an icon: Details here.
Geo location	Locations saved to a Geo location field will display in Map View. A Geo location field that is also a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref). has an additional Geographical map tab in the Find data for the field box, which allows users to select a point on a map and save that location to a record (details here):

HTML fields can be resized in both Display and Edit modes A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record., and any size change you make is remembered the next time you log in2 Collections version 1.17 onwards.. They are typically found on panels such as Accompanying texts and Inscriptions | Markings in object catalogue records. When placed over an HTML field's bottom right corner, the cursor changes to a double-headed arrow: click and then drag the corner to resize the field:

The field has a minimum size of about six standard single-line paragraphs plus the height required for the contextual toolbar.

Where records can be arranged in a hierarchy, a field can be configured to be inherited so that a record lower in the hierarchy inherits a value entered in a record immediately higher in the hierarchy (its parent). This can be efficient as a value only needs to be entered and saved in the parent record to be inherited by all of its children; importantly, while the value displays in a child record it is not stored in that record (in the child record the field is actually empty until the field is edited and the inherited value is overwritten).

In the following example, the Conditions governing access and Conditions governing reproduction fields are configured to be inherited and data has been added to both fields in a parent record:

When we view a record lower in the hierarchy, the values from the parent record are displayed in these two fields but with a dotted underline to indicate that they have been inherited:

An inherited value can be edited or deleted in the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance.. Here we see the Conditions governing reproduction field in Edit mode in a child record:

The value can be deleted entirely, or edited / rewritten. When you edit the record and add a value to an inherited field, the new value will not be underlined / faded as, of course, it is no longer inherited:

Tip: If you delete or edit an inherited value in a child record, it can be restored by right-clicking the field in Edit mode and selecting Restore inheritance from the context menu that displays.

In summary, when data in a field has a dotted underline (or it is faded / lighter grey than other data), it is displayed in the field but not saved in the current record. When you edit the field, the edited value is saved in the current record.

Occurrences and Inheritance

While field occurrences If a field in the current record can have more than one value, we add an occurrence of the field for each value (e.g. a book can have multiple authors so we add an occurrence of the author.name (au) field for each author). An occurrence can be a member of a group of fields, and adding an occurrence of the field adds all members of the group at once. in a parent record can be inherited by its children, it is important to understand the impact of editing a field occurrence in a child record. Consider this example.

A parent record has three occurrences of the title field:

and these are inherited by its child records:

If we edit a child record and change one of the occurrences, any following inherited occurrences of the field in that record will be lost. For example, if we change the second occurrence, the third inherited occurrence will be lost:

If we had changed the first occurrence in the child record, all subsequent inherited occurrences of the field in that record would have been lost.

Changing an inherited occurrence will not of course affect any non-inherited occurrences in the child record. In this example, the third occurrence in a child record had been edited and is no longer inherited from the parent record:

This is the result if we now change the first inherited occurrence:

How do you search for an inherited value?

If the value is not stored in the child record this raises the question: how do you search for a record using a value that is not actually stored in the record? The answer depends on your version of Collections. Details here.

The value that displays in a Merged-in field is pulled dynamically from a linked record. It is important to understand that the value is not actually stored in the Merged-in field, it only displays in the field; the value is stored in the linked record, and if it changes there, it automatically updates in the Merged-in field.

For example, Institution code in the Object Catalogue is a Merged-in field and it is associated with the Institution name Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref).:

When the Object Catalogue record in the example above was linked to the record in the Persons and institutions for The National Museum using the Institution name (institution.name (BA) Linked field, a value (NM in this case) was automatically displayed in the Institution code (institution.code (I2)) field. The Object Catalogue field institution.code (I2) does not store the value, it only displays it; the value is actually stored in the institution_code (BI) field in Persons and institutions:

As we will see below, this has implications when importing data into Collections.

In Edit mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record. a Merged-in field has no background colour or border (until the cursor hovers over it) and, obviously, it is not editable:

While Merged-in fields are always associated with a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref)., the linking does not need to be initiated from the current record The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance.. For example, an Exhibitions record lists objects that will be included in the exhibition on the Linked objects panel; the Exhibitions record is the primary record A link is made from one record (the primary) to another (the target)., that is the link is initiated from the Exhibitions record:

For each linked object the Exhibitions | Use of collections panel in the Object catalogue is auto-filled with data from the Exhibitions record (the name of the exhibition, dates, etc.); if the data is updated in the Exhibitions record, it is automatically updated in every linked Object catalogue record:

The implication when importing data into Collections may be clear now: data cannot be imported directly into a Merged-in field and if you attempt to do so, you will receive an error message similar to the one above. To return to our first example, we could import a value of The National Museum into the Institution name (institution.name (BA)) field in an Object catalogue record, but we obviously cannot import a value into the Institution code (institution.code (I2)) field because it does not hold data, it only displays data and the data that it displays is stored elsewhere.

If we wanted to import an Institution code value, it would need to be imported into the institution_code (BI) field in Persons and institutions.

More details

See How to link records for more details about these fields.

See Searching remote indexes for details about searching Merged-in fields.

Collections system can be multilingual, with fields configured to accept data in two or more languages. Note that not all fields in a multilingual system are necessarily configured to be multilingual and therefore translatable. As we see in the Field properties box in this example, the Notes field (dating.notes (DO)) is configured to be multilingual (Multi lingual = True):

Data in each available language can be viewed and edited by selecting a language from the Data language drop list in the Main menu (or the top Toolbar in earlier versions of Collections). Changing the Data language changes the language in which all your multilingual data is displayed and edited: any values you add to multilingual fields are associated with the selected language.

Changing the Data language changes the language in which all your multilingual data is displayed and edited. However, it is possible to edit multilingual values in a single field without changing the Data language. In versions of Collections prior to version 1.11, the Edit multilingual texts icon appears in the Record details View toolbar:

The icon is disabled until the cursor is in a (non-linked) multilingual field the value that displays in a Linked field is pulled from the linked record; in this case we translate the value in the linked record, not in the current multilingual field itself (more details here).

With the release of Collections 1.11 the Edit multilingual texts icon has been removed from the Record details View toolbar and displays in multilingual fields themselves to make it easier in Edit mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record. to identify whether a field is multilingual:

Depending on your version of Collections:

• Click the Edit multilingual texts icon in the Record details View toolbar (or use the keyboard shortcut, CTRL+M) when the cursor is in a multilingual field.

  -OR-

•  Right-click a multilingual field and select Edit multilingual texts from the context menu.

  -OR-

• Click the Edit multilingual texts flag in a field (Collections version 1.11 onwards).

The Multilingual Data box will open enabling you to view and edit data in all available languages for the current field and (optionally) specify that one of the translations is an invariant In a multilingual environment an invariant value is one that displays in any available language until a translation is provided: if an invariant value is English and it has not been translated into French, the English value will display when the Data language is French until a French translation of the value is provided.:

Details about working with multilingual fields and invariants can be found here.

When a field has a type of Period3 Collections version 1.15 onwards. it is possible to save and to search for date periods as a natural language value, such as 12th century, Spring 2023, and so on. Although such fields display the natural language version of a period, the indexed (searchable) value is stored in the database as an ISO start and end date range (i.e. a numerical value). For example:

Period entered by a user	Indexed value
12th century	1100.0101 - 1199.1231
Spring 2022	2022.0301 - 2022.0531
late 2018	2018.0901 - 2018.1231
Early 19th Century - 2022	1800.0101 - 2022.1231
1950s	1950.0101 - 1959.1231

When adding a value to a Period type field, and when specifying a search value, you use the natural language version of a period.

Validation takes place after leaving the field. If a value is entered that is not recognized, a warning displays and a different period value will need to be entered, e.g.:

Searching

When searching a Period type field the search value is specified as a complete natural language period, such as 12th century (any years must be specified as digits); do not use single words (not even truncated) from the natural language period (such as century) or ISO dates with months and/or days. Behind the scenes the natural language search value is converted to an ISO date range and matched against the indexed values.

Notes:

• It is only possible to search for a single date period, not date period ranges.
• Searching a Period type field in versions of Collections prior to version 2.0 is somewhat limited: the default search operator is equals and it is only possible to return records with dates that fall within the searched date range; from Collections version 2.0 onwards, a far wider ranch of search operators is available, including overlaps, which returns records with dates that intersect (cross over) the searched date range.

More details:

• How to perform a Standard search on a Period type field.

• How to perform a Advanced search on a Period type field.

Languages

Date values must be specified in the current User Interface language in Collections when editing or searching records. For example, if the current User Interface language is Dutch, a search might be:

my_period_field from "21e eeuw"

and if it is English, the same search would be:

my_period_field from "21st century"

The search result will be the same in both languages as the indexed value is an ISO date range that is language independent.

Supported languages are currently:

• British English
• Dutch
• Danish
• Welsh
• Portuguese
• Swedish